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INTRODUCTION 


The initial installation of CP-67 involves running CMS 
on the bare machine. CMS is used to load the CP-67 basic 
distribution tape onto a disk, read in the REALIO 
configuration for the installation and assemble the REALIO 
and other modules, if necessary, to select the desired 
options. Once this is done, an EXEC procedure is invoked to 
punch the CP-67 nucleus, utilities, and loaders. The 
punched decks are then used on the bare machine to format 
the CP-67 volumes (sysres, drums, etc.) and to load the 
nucleus and directory on the residence volume. If CP-67 is 
already installed, regenerations or new installations can be 
performed from a CMS virtual machine. 


Version 3 Level 0 of CP-67 has many new features that 
make it incompatible with previous versions. For this 
reason, users must not use utilities, loaders, or nucleus 
decks from previous releases. In particular, the real 
machine configuration description requires additional 
information to produce a valid RIO module. 




IFISTAItTNG CP-67 


CMS FOR CP-67 SYSGEN 


To obtain CP-67, the CMS system is used. A description 
follow^ of how to obtain CMS and run it on the real machine 
(not under CP). This description is intended as a 
convenient summary, as more detailed information can be 
found under "Installing CMS". 


First, restore the DUMP/RESTORE copy of the CMS System 
disk. The CMS System tape contains the following files; 

file 1—IPL'able DDMP/RESTORE 

file 2—a D/R copy of the CMS System disk. 


Then, IPL the restored disk. Hit REQUEST on the 1052 
console. CMS now allows you to reconfigure the CMS device 
address table to match the real device configuration of the 
installation. The following question is asked: 

Ql: REDEFINE ADDRESSES? {YES,NO): 

Answer YES, if the real addresses are different 
from the standard CMS virtual addresses. 

It is then necessary to enter the four-digit addresses 
for the following devices; console, S-disk, P-disk, reader, 
punch, printer, tape one, and tape two. Answer NO to the 
CP-SAVE question. 

The standard CMS device addresses are listed below. 


Device 

Virtual 

Address 

Symboli 
Name 

c 


1052 

009 

CONI 

console 


2311,2314 

190 

DSKl 

system disk 

(read-only) 

2311,2314 

191** 

DSK2 

permanent disk (user files) 

*2311,2314 

192** 

DSK3 

temporary di 

sk (workspace) 

*2311,2314 

000** 

DSK4 

A disk (user 

files) 

*2311,2314 

000** 

DSK5 

B disk (user 

files) 

*2311,2314 

190** 

DSK6 

C disk (user 

files) 

1403 

OOE 

PRNl 

line printer 


2540 

OOC 

RDRl 

card reader 


7 " ri A 

Z V 

GOD 

PCHl 

card punch 


*2400 

180 

TAPI 

tape drive 


*2400 

181 

TAP 2 

tape drive 


231!! or 3^1'’ 

^ 

temtKJrarv disk 

the , B * S’ —a 

■ w dis 

iCi. 

le "cwo z 

HXjO 'Ccl'p0 (dlTXVtdo 
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devices; they are not included in the minimum 
configuration. 

** The specified virtual addresses may be changed at any 
time by the CMS LOGIN command. 


After entering the real device addresses, the CMS 
» initialization message is typed 

CMS .. VERSION n LEVEL m 

Issue the CMS command 

- FORMAT P ALL 

to format the P-disk to be used for CP-67 SYSGEN. The 
card punch and printer should be placed in READY 
status. 


Place the CP distribution tape on symbolic drive 
TAP2 and issue 

TAPE LOAD 4 

All necessary CP files are loaded onto the P-disk. 
These files are of the following filetypes for 
generation of CP-67 and the utilities: 


SYSIN files, which are the CP source decks written in 
Assembler Language; 

EXEC files, which contain procedures for assembling and 
updating; 

TEXT files containing the assembled modules of the 
system; 

MACLIB files containing CP-67 macros for assembling the 
system and the real machine configuration; 

ASP360 and COPY files for creating and changing the 
macro library CPMACS MACLIB, when necessary; 

LOADER files containing relocating loaders with 
different printer addresses (that is, 000, OOE, OOF, 
010, 030, 040); 

SAMPLE files containing examples of the various decks 
required for system setup. 


It is ircm this P~5.isk (on ’which the above 

loaded) that the CP system is obtained. 


- 3 




Note . While executing CNS on the real machine, the last 
card of any punched deck must be manually run out from the 
card punch. 


SETUP OF {MACHINE CONFIGURATION 

The real machine configuration is described to CP via a 
text deck (object deck). This text deck is the result of 
assembling a group of real I/O definition macros with the 
CMS Assembler (F). A real machine configuration is contained 


among the P-disk files 

as RIOCSC TEXT. The configuration 

that RIOCSC supports is 

as follows: 


Device 

Address 


1052 

009 


1403 

010 


2540R 

Oil 


2540P 

012 


2703 

030-03F 

(8 level ASCII, 



110 bps Lines *) 


040-04F 

(2741 and 1050 Lines) 


050-05F 

(2741 and 1050 Lines) 


060-06F 

(2741 and 1050 Lines) 


070-07F 

(2741 and 1050 Lines) 


080-087 

(2741 and 1050 Lines) 

3 2400*s 

OCO - 0C2 


4 2703 BSC 

088-C8B 


2 2311*s 

390 - 391 


2314 

230 - 237 


2314 

260 - 267 


2314 

330 - 337 


2301 

101 


2301 

100 



* The customer is responsible for term.inal compatibility 
with this program. IBM assumes no responsibility for 
the impact that any changes to the IBM-supplied 
products or programs may have on terminals provided by 
others. 

If the above configuration does not match the installation's 
configuration, a real I/O source deck must be constructed 
hy using the macros specified in Section IV and the deck 
must be read in and assembled. Sample simplex and duplex 
machine configurations are contained among the P-disk files 
with the identifiers of SIMPLEX SAMPLE and DUPLEX SAMPLE. 


Tc get the real I/O definitions for the target 
confi.miration read onto the P—disk, from 

i-— *'nw. w -.i.iif <2.110. xsou.^ Ciio 
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Tlie assembled niodules distrib’ated with this system 

contain the following options: 

6ETIMR SETA 6 

6V67 SETA 1 

&ISAM SETC 'YES* 

If these options are not desired or are to be changed, 
update the LOCAL COPY file and reassemble the modules 
affected, as described for each option below. 


Real Timer—6RTIMR 


The real timer option SRTIMR provides for updating a 
virtual machines timer when the machine is in wait state, if 
that virtual machine has the REAL TIMER option in the 
DIRECTORY. This option allows a dormant machine (for 
example, APL) to be awakened by a timer interrupt. (See 
CP-67 Operator’s Guide —"Directory Creation"—for details.) 


The module to be assembled for the SRTIMR option is 
DISPATCH. 


For the real timer option the SETA symbol is set to the 
number of concurrent real timers that the installation is 
willing to support. For instance, the statement 

SRTIMR SETA 6 

produces code in the dispatcher to maintain up to six real 
timers. 

Virtual 360/67 Option—SV67 


The virtual 67 option, SV67, provides code in the CP-67 
nucleus to support virtual machines in which CP-67 can be 
run. Those virtual machines v?ith the virtual 67 option 
specified in the directory have the facility to operate in 
virtual extended PSW mode with 24-bit addressing. The 
distributed system has the SV67 option selected. If the 
option is not desired, change the LOCAL COPY value to 

SV67 SETA 0 

and use the exec procedure CPDPASM to reassemble the 
following modules: 

CFSMAIN 

DISPATCH . 

Ox i 4 
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LOGON 

MVIOEXEC 

PAGTRANS 

PROGINT 

QUEVID 

RESINT 

PSA 

UNSTIO 

DSEROFF 

VIOEXEC 


ISAM Option—SISAM 


The gISAM option allows the user to do I/O operations 
involving self-modifying CCW commands on DASD device such as 
used by OS/360 ISAM. Only those users with the ISAM option 
in the DIRECTORY have their CCW strings checked for 
self-modifying operation; thus not all users incur the 
additional CP overhead. 

The module to be assembled for the &ISAM option is 
CCWTRAN. The distributed version has the option selected. 

If the option is not desired, change the LOCAL COPY 
value to 

SISAM SETC ’NO* 
and issue the CMS command 
CPUPASM CCWTRAN 


Note . The above procedure for options can also be applied 
to code added by an installation. The module can be 
assembled to selectively contain the installation's code 
(1) by placing a COPY OPTIONS and a COPY LOCAL instruction 
before the START card in the module being modified, (2) by 
adding a SETA instruction in the LOCAL COPY file, that is, 

SRTIMR SETA 1 

and (3) by checking for the setting of the option in the 
module. 


OBTAINING CP-67 


To obtain the 
must be punched 

utiJ-xoies anci card 
READY status, then 


tailored CP-67 system, a card load deck 
out and then loaded onto a properly 

To minch the CP card load deck, the CP 
loaders, verify that the card p'onch is in 
issue the CMS command: 




CPGEN SI &2 


where 

61 is the address of the printer that the loader 
uses to print the CP load map. A loader 
called RELDRxxx punches at the start 

of the deck, where xxx, specified in 61, is 
«> the printer address in 3 hex characters 
(for example, OOE or 030). 

62 is the full name of the real I/O configuration deck 
that was specifically assembled for the system 

in the procedure above (for example, RIOCSC or 
RIOABC). 

The above command punches out the complete CP load deck 
(about 2500 cards with each text deck uniquely identified in 
columns 73-75) and each deck is separated by an identifying 
card with the format 

OFFLINE READ fname ftype 

where fname is the object deck filename and ftype is TEXT. 


Note . There is a pause after punching the CP-67 LOAD DECK 
to allow the user to clear the punch and get the last card. 
The user can continue by typing "ready" or he may stop here 
by typing "quit". This is clearly stated on the terminal as 
the CPGEN operation proceeds. 


OBTAINING THE UTILITIES 


The utilities supplied with CP-67 are as follows: 

BUZZARD 

DIRECT 

FORMAT 

SAVESYS 

VDW5P 

The CP utilities are punched out as part of the CPGEN 
procedure above. The second file output contains all the 
utilities, each identified by a deck separator of the 
OFFLINE READ form (as outlined above for the CP load deck). 


The CP utilities, BUZZARD, FORMAT and SAVESYS, are 
stand-alone programs and must have the appropriate loader on 




DIRECT utility runs stand-alone or under CMS. If it is run 
stand-alone, it requires a loader- The VDOMP utility runs 
only under CMS. It is used to retrieve CP-67 dumps from 
disk after an ABEND in the CP supervisor. T}ie VDUMP utility 
is run by the user specified in the SYSGEN macro of RIOxxx 
as the SYSDUMP parameter. In addition to the standard CMS 
machine configuration, the user must also have a printer 
Reader device in his virtual machine as 

UNIT 0F1,RPRT 

in order to run VDUMP. (See CP-67 Operator’s Guide —"VDUMP" 
under "Utility Operation", and "Directory Creation"—for 
details.) 

To obtain copies of the loader, issue the CMS command 
OFFLINE PUNCH name LOADER 

where name is either RELDROOO, RELDROlO, RELDR030, RELDROOE, 
RELDROOF, or RELDR040, depending on the real address of the 
printer. 


If an installation has a printer of any other address, 
use the RELDROOO LOADER and immediately after the loader and 
before the TEXT file(s) to be loaded place the following 
control card: 

column 12 6 10 

CTL WTR ecu 

column 1 - 12, 2, 9 punch 

where ecu is the desired printer address. 


The CPGEN procedure punches out three loaders for the 
specified printer address 61 (that is, OOE) to be used with 
various loading functions and also three loaders with a lo 
address (RELDROOO), which are useful when loading the CP 
utilities. 


Note . If a loader RELDROOO is used, no load map is 
produced, but the loading function proceeds. A load rr-r-r- 
very useful for the CP-67 system, but of little use vdiCn 
loading the utilities, thus RELDROOO can be used by an 
installation to load a program without using the printer. 


FORMATTING OF VOLUMES 


Once the CP utilities 

..iirect- access voruaes used 


have been punched out, 
by the system (for pagr.c-s 





spoolimj* nv3ci.eus residence, and directory) must be properly 
formatted. This is accomplished by means of the FORMAT 
utility. The detailed instructions for operating FORMAT are 
contained in CP-67 Operator’s Guide. 


The system*s residence volume for CP is usually 
formatted with the label CPDSKl, as that label is required 
for IPL^ng by name. If it is desired to change the volume 
label, the file SYSTEM SYSIN must be modified to reflect the 
desired system's residence volume label and SYSTEM SYSIN 
must be reassembled and replaced in the CP load deck- 


ALLOCATION AND DIRECTORY CREATION 


All 2314 and 2311 volumes to be used for CP-67 spooling 
and/or paging must have space allocated. The system 
residence volume must have space allocated for the system 
directory and the nucleus. 

Note ; 2301 and 2303 drums must not be allocated since they 
are specially formatted for dynamic paging allocation. The 
DIRECT utility (ALLOCATE control cards) is used to allocate 
space for the system residence volume and others, if 
necessary. (See CP-67 Operator's Guide for details). For 
2314 residence, the following space must be allocated as 
permanent; 


Cyl. Usage 


to 


() 

•EYSERR* 

•SYSWRM * 
•SYSDNC* 
'EYSDNC+1* 


IPL and file directory 
error recording (1 cyl required) 
warm start control (1 cyl required) 
nucleus residence (2 cyl required) 
nucleus residence 


The values for the symbolic cylinder locations are 
defined in the RIOxxx deck with the SYSRES macro. 


For 2311 residence, the following space must be 
allocated as permanent; 


C^^l. Usage 


to 


0-1 

•£:YSERR' 

•SYSWRM’ 
•SYSDNC* 
'SYSDNC+4* 


IPL and file directory 
error recording (1 cyl required) 
warm start control (1 cyl required) 
nucleus residence (5 cyl required) 
nucleus residence 


The 

specif--OQ 


symbolic values are obtained from the SYSRES macro 
in the real machxne configuratioii description. 



Cylinder 0 and others rnay be allocated as BRCT space. 
In addition, some cylinders may be allocated as permanent 
for user file space or named system residence. Other 
cylinders must be allocated as TEMP (for spooling or paging) 
or TDSK. 


* The directory must be created after the direct-access 
volumes are properly formatted. The detailed instructions 
for setting up a directory deck are contained in the 
CP-67 Operator's Guide . A sample directory is contained on 
the P-disk in the file DIRECT SMIPLE. To obtain a printout 
of that file, issue the CMS command 

OFFLINE PRINT DIRECT SAMPLE 


The directory is created by the utility DIRECT, the 
instructions for which are in the operator's guide. The 
allocation of space on the residence volume (as described 
above) must precede the directory creation. 


CREATION OF PERMANENT RESIDENCE VOLUME 


Once the volumes have been formatted and the directory 
created, the permanent CP residence nucleus should be 
created from the CP LOAD DECK. The last module in the CP 
load deck is the SAVECP module (serialization SCP). The 
function of this module is to create, after the load through 
the card reader, an IPL'able copy of CP on the residence 
volume from the core image. The volume address, label, and 
nucleus cylinders are indicated to SAVECP from information 
contained in the RIOxxx module, in particular, the 
information from the SYSRES macro. 


To create the permanent CP residence volum.e, ready the 
CP load deck into an available reader. The first module in 
the load deck must be the relocating loader, which prints 
the load map of the system onto the printer. Perform an IPL 
sequence on the card reader. The volume must be mounted and 
ready before the load completes. It is advisable to clear 
core before loading. If the disk is not ready, the message 

**** DISK CUU NOT READY *++♦ 
is printed. 

If the label on the disk is incorrect, the message 

* + VOLTD NOT dlabel 


“ 11 - 




is printed. 

If either iressage is printed, remedy the situation and press 
the EXTERNAL button to retry, or start from the card load. 

At the termination of the load and the creation of the 
residence volume, the following message appears on the 
operator's terminal: 

^ DISK LOAD OK 

At this time, the permanent CP residence volume has been 
created and may be IPL'ed to initiate system operation. 




OBTAINING CP-67 FROM AN EXISTING CMS 


For those installations that have an operating 
CP-67/CMS system, the CMS restore procedure outlined above 
can be bypassed. The following steps can be used to obtain 
CP-67: 

1. Mount the distribution tape on an available tape 
drive attached to the desired userid as *181'. 

2. Using CMS issue a TAPE LOAD 4 command. The four 
files will then load in their entirety onto the user's 
P-disk space. 

Note . About 40 cylinders of 2314 space are adeguate to 
hold all the files and do assemblies. 

3. Perform any necessary assemblies for configuration 
or options as outlined under "Setup of Machine 
Configuration" and "Selection of Options". 

4. Follow the procedure under "Obtaining CP-67" using 
the CPGEN command. 

5. BE SURE TO USE THE NEW UTILITIES AND THE NEW 
LOADERS WITH THE NEW CP-67. 
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'CP-67 EXEC PROCEDURES 


The following CMS EXEC procedures are distributed with 
the CP-67 system. These procedures should be used to 
generate and maintain the system. 


CPUPASM 
CPUPASM SI g2 

CPUPASM is used to update a SYSIN file with an UPDATE file, 
if it exists, and to assemble the updated file or the 
original if no UPDATE file exists. &1 is the name of the 
SYSIN file to be processed- £2 can be NODECK if no TEXT 
file is to be produced. The original SYSIN and UPDATE files 
remain. The TEXT file created is for the updated version 
and is named 61 TEXT if no UPDATE file is applied, or .51 
TEXT if an UPDATE was applied leaving the original 61 TEXT. 
No LISTING file is produced. 


Note that the CPGEN/CPSYS/CPPUNCH EXEC functions 
described below use .61 TEXT in preference to 61 TEXT- 


CPMACGEN 
CPMACGEN 61 

CPMACGEN creates a MACLIB, named 61 MACLIB, from all COPY 
and ASP360 files on the P-disk. The COPY and ASP360 files 
should bCxupdated using CPUPMAC before using this command. 


CPMACADD 
CPMACADD 61 62 

CPMACADD adds file 62 (either ASP360 or COPY) to MACITB 
named 61. The MACLIE must already exist and the ASP360 or 
COPY file should be updated before adding the file. 


CPMACREP 


CPMACREP 61 62 


62 (COPY or ASP360) in 

already exist and the 


the MA-.CLTB 

asPSljO cr 


CPMACREP replaces the file 
named 51. The MACLIB must 
COPY file should be updated before replacement. 

Note . The ASP360 file may contain more than one KACTO 
definition. If one macro is changed the entire file 
(ASP360) must he or replaced, not the macro 




CPGEN 


CPGEN SI £2 

CPGEN is used to punch a self-loading CP nucleus, the CP 
utilities, and CP loaders. 

61 = 0(f0| 010 I 030 1 040 | OOE 1 OOF 

Select the correct relocating loader for the 
installation, where the three characters indicate the 
system's printer address. 

62 = The name of the installation’s real I/O configuration 

deck, for example, RIOCSC. 


CPUPMAC 
CPUPMAC 61 

CPUPMAC updates a 61 KASTEP. file if it exists, and produces 
a 61 COPY or a 61 ASP360 file. If a 61 MASTER file does not 
exist, CPUPMAC updates an 61 COPY or 61 ASP360 file with 61 
UPDATE, saving the old file as 61 MASTER and creating the 
updated file as 61 COPY or 61 ASP360. There must be an 61 
UPDATE file on the users disk, as well as a 61 COPY or 61 
ASP360 file. 

Note . This command must be used on all ASP360 or COPY files 
which, have updates, before using CPMACGEN. 

Hint . Instead of regenerating CPMACS MACLIB every time an 
ASP360 or COPY module is changed, it is more convenient to 
create a new MACLIB called MACUP MACLIB. The assemble 
procedures automatically access MACUP before accessing 
CPMACS. 


CPSYS 

CPSYS 

This EXEC procedure is used by the CPGEN EXEC function to 
produce the CP-67 load deck. It contains control statements 
and an ordered list of the nucleus components. 
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CPPUNCH 


CPPUNCH 61 &2 

This EXEC procedure is used by the CPSYS EXEC function in 
the CPGEN procedure. Its function is to select either the 
.61 TEXT file if it exists or the 61 TEXT file. If neither 
exists, an error message is printed. 

CPLIST 
CPLIST 61 

This EXEC procedure prints one or all files from a CP-67 
LISTING tape generated by the CPASMGEN EXEC procedure. The 
first file on the listing tape must be a TAPE LOG file. The 
TAPE LOG file is merely a sequential list of the names of 
the LISTINGS that follow. For example, see TEMP EXEC. If 
61 is ALL then all files (66) are printed, otherwise the 
tape is searched for the desired file (for example, 
DISPATCH) and that file (DISPATCH LISTING) is printed. 


CPASMGEN 
CPASMGEN 61 

This EXEC procedure is the one used to completely assemble 
the CP-67 system producing a printed listing and a LISTING 
tape. An auxiliary EXEC procedure with an ordered list of 
all SYSIN is necessary for complete generation. For 
instance, if TEMP EXEC consists of the following: 

61 62 ACCTON 

61 62 ACNTOFF 

61 62 ACNTIME 

etc. 

then the following CMS procedure assembles all the modules 
in TEE'.P EXEC: 

TEMP EXEC CPASMGEN 


CPTGEN 

CPTGEN 61 62 


This EXEC procedure is used only when running under CP-67, 
since it uses the XFER function. Its purpose is to create 
an IPL'able tape for CP-67 disk loading. The 61 is the name 
of the desired loader for the printer (for example, RELDROOE 
or RELDR030). The 62 is the name of realio confiauration 


(for exami 




Cl ot: C U A 


CPSYS EXEC procedure to produce a load deck. A tape must be 














CP- 67 DECK FORMATS 


This section describes the format of the CP load deck 
and the utilities. The name of each deck and its 
serialization in columns 73-76 are specified. 


CP-67 SYSTEM 

I 

The following text files are contained in the CP load 

deck: 


Module Serial 


Relocating Loader (RELDRxxx) 


/SLC 
PSA 

ACCTON 

ACNTOFF 

ACNTIME 

CCWTRANS 

CFSCOM 

CFSDBG 

CFSIPL 

CFSMAIN 

CFSPRV 

CFSQRY 

CFSSET 

CFSSPL 

CFSTACH 

CHKCUACT 

CONSINT 

CONVRT 

CPFILE 

CPSTACK 

CPSYM 

DEDICATE 

DIAL 

DISPATCH 

DSKDUMP 

EXTEND 

FREE 

lOINT 

lOERROR 

LINK 

LOGON 

LOGFILFS 

MRICEXEC 

KVIOEXEC 

PACK 

PAGTRANS 

PAGEGET 

PLACE 

PROGINT 

't'- —> -i- --' 

RDCONS 


000080 


loader control card—with PSA 

PSA 

ACON 

ACOF 

ACNT 

CCW 

CCOM 

CDBG 

Cl PL 

MAIN 

CPRV 

CQRY 

CSET 

CSPL 

TACH 

CKCO 

CINT 

CVT 

CPF 

CPK 

CPSM 

DED 

DIA 

DISP 

DSKD 

XTND 

FREE 

lOI 

lERR 

LINK 

LOG 

LGFL 

MRIO 

MVIO 

PACK 

PAGE 

PGET 

PLC 

PROG 

W 

RDCN 




RDSCaN 

RDS 





RECFREE 

REC 





RESINT 

RST 





RIOxxx 

RIO 





SCANUNIT 

SUN 





SLTSIM 

SLT 





STCONSIO 

SCN 





TMPSPACE 

TMP 


' 



UNSTIO 

DNS 





UNTRANS 

UNTR 





USERLKP 

DLKP 





DSEROFF 

DSE 





VIOEXEC 

VIOX 





VSERCH 

VSS 





WRTCONS 

WCN 





ICS CPEND 

loader 

control 

card- 

-with 

IPL TEXT 

SLC 020000 

loader 

control 

card- 

-with 

IPL TEXT 

IPL 

IPL 





SLC 020800 
CPLOCS CPLC 

loader 

control 

card- 

-with 

CPLOCS TEXT 

SLC 021000 

loader 

control 

card- 

-with 

SYSTFM TEXT 

SYSTEM 

SYS 





SLC 022000 

loader 

control 

card- 

-with 

CHKPT TEXT 

CHKPT 

CHRP 





SLC 023000 

loader 

control 

card- 

-with 

CPINIT TEXT 

CPINIT 

CPI 





SLC 025000 

loader 

control 

card- 

-with 

SAVECP TEXT 

SAVECP 

SCP 





LOT SAVENUC 

loader 

control 

card 




CP UTILITIES 

The following files are the CP utilities; 


Module 

Serial 

BUZZARD 

BUZ 

DIRECT 

DIR 

FORMAT 

FOR 

SAVESYS 

SSYS 

VDUMP 

VDMP 
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■ MACHINE CONFIGURATION DEFINITION 
FOR CP-67 


A description of the physical machine must be provided 
for CP-67. This description is contained in the text deck 
RIOCSC. If the distributed RIOCSC text deck does not meet 
the installation’s configuration (see "Setup of Machine 
Configuration"), a new real I/O deck must be constructed 
►from the macros described below, assem.bled, and used in 
place of the distributed RIOCSC text deck. 


The physical (real) machine is described to CP via 
control blocks containing information about the input/output 
devices, channels, and control units. These control blocks 
are generated by the following CP-67 macros which are 
described below: REALIO, SYSRES, SYSGEN, SIMPLEX, DRCH, 
DRCU, DRDEV”, and DMXDV. 


The following conventions are used throughout this 
description: 1. variable information is indicated in 
lowercase and system key-words are indicated in uppercase 
letters, whereas they are written in uppercase when macros 
are punched in cards; 2. < and > are used to bracket 
choices and the brackets are not part of the macro 
definition (for example, RDEVPNT=<0,dlabel>) would be tised 
to indicate that RDEVPNT=0 or RDEVPNT=dlabel could be used; 
3. a pair of j’s is used to indicate an optional parameter 
and the |'s are not a part of the macro definition (for 
example, SIMPLEX jnj would be used to indicate that SIMPLIIX 
or SIMPLEX n could be used). 


CP-67 MACROS 


REALIO MACRO 


The REALIO macro is the first card of the deck. It;? 
purpose is to generate the prerequisite entry points for use 
by the system and to give a CSECT name to the deck. Its use 
is • 

flabelj REALIO iTITLE=’Listing Header'| 

where "label” becomes the alphabetic serialization cf ti.e 
text deck and title appears at the top of the pages in the 
listing. 

Note , label must be four or fewer characters. 


~ 1-d 




SYSRES■MACRO 


The SYSRES macro is used to describe the system 
residence volume. Its format is 

SYSRES SYSRES=ccu,SYSTYPE=type,SYSVOL=volid,SYSERR=aaa, 

SYSDNC=bbb,SYSWRM=ccc 

where oscu is the address of the disk onto which the nucleus 
is written; type is 2311 or 2314,; volid is the CP-67 
formatted label of the volume (that is, CPDSKl); aaa is the 
cylinder allocated as permanent for error recording; bbb is 
the starting cylinder for nucleus residence; and ccc is the 
cylinder for warm start control. 


SYSGEN MACRO 

The SYSGEN macro is used to describe certain installation 
variables used for system operation. Its format is 

SYSGEN SYSOPER=userid,SYSDUMP=dum.pid,SYSEMRG=xxx, 

SYSCNSL=aaa, SYSP.RT=bbb, SYSPUN=ccc, SYSCORE=dddK 

where userid is the operator's id for AUTO LOGIN; dumpid is 
the user's id for whom system dumps are made available from 
spooling files; xxx is the 270x line address for the 
emergency console startup; aaa is the system console 
address; bbb is the system line printer; ccc is the system 
punch, and ddd is the storage size of the real system 
expressed in K. 


SIMPLEX MACRO 


The SIMPLEX macro follows the unit, control unit, and 
channel specifications for any given CPU. It provides for 
the creation of the necessary tables required by CP and is 
dependent on the configuration specified. If a simplex 
configuration is described, the SI^'^PLEX m.acro must be 
follow-5d by the END card. If a duplex configuration is being 
described, two SIMPLEX macros are required: the first 
SIMPLEX macro is followed by the I/O definitions for another 
CPU; the second SIMPLEX macro is followed by the END card. 

SIMPLEX |nl 

where 'n* is either null for a simplex system, *1' for the 
first half of a duolex specification, or '2' for the second 
half of a duplex configuration. 






I/O BLOCK DEFINITION MACROS 

The following macros are used to describe the physical 
input/output units available: 


Define Channel Macro 

I labelj DRCH j CHANPNT=<0,chlabel> j, 

RCULIST=1iSt,CHANADD=c 

where "label" is the symbolic label of this channel; chlabel 
is the symbolic label of the next channel in the channel 
list; list is the symbolic label of the first control unit 
on this channel; and c is the channel address. 

Define Control Unit Macro 
jlabelI DRCU jRCUPNT=<0,culabel>|, 

DEVLIST=dlabel,RCUADD=c, 

IRCUPATH=<0,path> j,CUTAILl=taill 


where "label" is the symbolic label of this control unit; 
culabel is the symbolic label of the next DRCU macro for the 
next control unit on this channel, if any; dlabel is the 
symbolic label of the first device defined for this control 
unit; c is the control unit address; path is the value 
(hexadecimal) of the logical path for this control unit 
(each control unit on a channel has a unique bit of the 
eight bits assigned to the channel and this bit or path 
defines which devices are accessed through this control 
unit); taill provides a connection to this control unit from 
the channel—use the symbolic label of the channel on which 
this control unit resides. 





Define Device Kacro 


1labelI DRDEV (RDEVPNT=<0,dlabel>1, 

RDEVCU=culabel,RDEVADD=CCU, 

TYPE=type,DECUPTH=path, 

where "label" is the symbolic label for this device; dlabel 
is the symbolic label of the next device on this control 
unit; culabel is the label of the control unit on which 
this device resides; ecu is the channel, control unit, and 
unit address of this device; type is the device type 
(specified as xxxx where xxxx is 2311, 2314, 2321, 2301, 
2303, 2400, 1403, 2540P, 2540R, 2701, 2702, 2703, or 2250; 

"path" is identical to the control units path (RCUPATH in 
DRCU) for this device and defines which control unit this 
device uses. 


Define t^ultiplexor Device Macro 


1 label I DMXDV RDEVADD=ccu,TYPE=type, |SAD=n|, 

1RDEVPNT=<0,mlabel>I 

where "label" is the symbolic label of this multiplexor 
device; ecu is the channel, control unit, and unit address 
of this device; type is the device type, which is one of 
the following: 1052', 1403, 2540RDR, 2540PCH, 2701T, 2702T, 

2703T, or TT35T ( where the 2701T, 27021, 2703T implies a 
1052, 2741-BCD or 2741-correspondence terminal coming into a 
2701, 2702, or 2703 and the TT35T is a teletype 33 or 35); n 
is the .SAD address of the 2701, 2702, or 2703 and has a 
value of 0, 1, 2, 3, or 4 (the SAD address does not indicate 
terminal type); For a 2701 which does not require a SAD 
command, specify a value of 4. For a 2703 which ignores SAD 
commands, a value of 4 can also be specified. For a 2702, 
the correct SAD value for the particular line must be 
specified ( 0, 1, 2, and 3 are valid). Your local IBM CE 

can supply you with the SAD numbers for each 2702 line; and 
mlabel is the symbolic label of the next multiplexor device 
in the chain. There must be one DMXDV macro defined for each 
2701, 2702, or 2703 line. 


Note . The ordered arrangement of the real I/O macros is 
required to properly generate the correct entries and 
tables. 


The multiplexor devices mast be defined before the 
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selector channel devices. Each selector channel must be 
completely defined in terms of devices, control unit, and 
then channel (in that order) before the next selector 
channel is defined. If a simplex configuration is being 
described, the SIMPLEX macro must be followed by the END 
card. If a duplex configuration is being described, two 
SII'IPLEX macros are required: the first SIMPLEX macro is 
followed by the I/O definitions for another CPU; the second 
SIMPLEX macro is followed by the END card. 


An example of a real I/O source deck for a simplex 
configuration is as follows: 

RIOS REALIO TITLE='SAMPLE SIMPLEX* 

SYSRES SYSRES=230,SYSTYPE=2314,SYSVOL=CPDSK1,SYSERR=004, * 
SYSDNC=198,SYSWRM=202 

SYSGEN SYSOPER=OPERATOR,SYSDUMP=CPSYS,SYSEMRG=020, ♦ 

SYSCNSL=009,SYSPRT=030,SYSPUN=032,SYSCORE=768K 
OPCONSOL DMXDV RDEVPNT=PRINTER1,RDEVADD=009,TYPE=1052 
PRINTERl DMXDV RDEVPNT=CARDRDR1,RDEVADD=030,TYPE=1403 
CARDRDRl DPjXDV RDEVPNT=PUNCH1 ,RDEVADD=031 , TYPE=254 ORDR 
PUNCHl DMXDV RDEVPNT=TERM01,RDEVADD=032,TYPE=254OPCH 
TERMOl DMXDV RDEVPNT=TERM02,RDEVADD=020,TYPE=2702T,SAD=1 
TER^J02 DMXDV RDEVPNT=TERM03 ,RDEVADD=021 ,TYPE=2702T, SAD=1 
TERM03 DMXDV RDEVPNT=TERM04,RDEVADD=023,TYPE=TT35T,SAD=2 


TERM4E DMXDV RDEVADD=04E,TYPE=2703T,SAD=4 

DRUM2 DRDEV RDEVCU=R2820A,RDEVADD=100,TYPE=2301,DECUPTH=80 

R2820A DRCU DEVLIST=DRUM2,RCUADD=0,CDTAIL1=CHAN1,RCUPATH=80 

CHANl DRCH RCULIST=R2820A,CHANADD=1,CHANPNT=CHAN2 

DI5K30 DRDEV RDEVCU=R2314,RDEVADD=230,TYPE=2314,DECUPTH=40, * 

RDEVPNT=DISK31 

DISK31 DRDEV RDEVCU=R2314,RDEVADD=231,TYPE=2314,DECUPTH=40, + 

RDEVPNT=DISK32 


DISK37 . DRDEV RDEVCU=R2314,RDEVADD=237,TyPE=2314,DECUPTH=40 

R2314 DRCU DEVLIST=DISK30,RCUADD=3,CUTAIL1=CHAN2,RCUPATH=40 

CHAN2 DRCH RCULIST=R2314,CHANADD=2,CHANPNT=CHAN3 

DRUMl DRDEV RDEVCU=R2841B,RDEVADD=393,TYPE=2303,DECUPTH=80, * 

RDEVPNT=DISK4 

DISK4 DRDEV RDEVCU=R2841B,DEVADD=390,TYPE=2311,DECUPTH=80, * 

RDEVPNT=DISK5 


R2841B DRCU DEVLIST=DRTO!l,RCUADD=9,CUTAIL1=CHAN3, RCUPATH=80, 

RCUPNT=R2250 

SCOPEl DRDEV RDEVCD=R2250,RDEVADD=306,TYPE=2250,DECUPTH=40 

R2250 DRCU DEVLIST=SCOPEl,RCUADD=0,CUTAIL1=CHAN3,RCUPATH=40 

CHAN3 DRCH RCULIST=R2841B,CHANADD=3,CHANPNT=CHAN0 

TAPEl DRDEV RDEVCU=R2400A,RDEVADD=0C0,TYPE=2400,DECUPTH=80 * 

RDEV’PNT=TAPE2 

TAPE? DRDEV RDEVCO=R2400A ..RDEVADD=0C1 .TYPE“2400 , DECT.TPTH=8 0 
u... ■ ^ wV ^j-,EC—u,eu i.j-jl—uMANO, ncuPAirl—80 
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DRCH RCULIST=R 2 4 0 0A,CHA«ADD=0,CHANPMT=CHANOA 

DRDEV RDEVCU=R2701A,RDEVADD=010,TYPE=2701.DECUPTH^eO 

DRCU DEVLIST=D27 0lA,RC OADD=l,CUTAILl=CHANOA,RCUPATH= 8 0 

DP.CH RCULIST=R2701A,CHA!:JADD=0,CHANPNT=CHAN0B 

DRDEV RDEVCU=R27013,RDEVADD=012,TYPE=2701,DECUPTH=80 

DRCU D£VLIST^D2701B,RCUADD=1,CUTAILl=CHANOB,RCUPATH=80 

DRCH RCULIST=R2701B,CHANADD=0 

SI^^PLEX 

END 


Note . ^ Nonshared rriultiplexor devices, except for tapes, 
should be defined as separate channel, control unit, and 
device blocks (iriacros) ; that is, each device has its own 
set, as shown for D2701A and D2701B above. This avoids 
lock-out problems on that channel if unusual I/O operations 
are performed by users on a particular device. 


CHANO 

D27C1A 

R27C1A 

CHAEOA 

D27C1B 

R2701B 

CHANGE 


Further examples of REAL I/O configuration decks are 
available from the CP-67 distributed P-disk files: SIMPLEX 
SAMPLE, DUPLEX SAMPLE, and RIOCSC SYSIN . 






GENERATING "NAMED* OPERATING SYSTEMS 


UNDER CP-67 

Providing a user with the capability of performing an 
IPL function by name, rather than by device, requires the 
installation management to save a copy of this system on a 
DASD device in paging form. The self-loading deck which 
performs this is entitled SAVESYS. It accepts a control 
^ard of the form 

SAVE VOLID=cccccc,UNIT=ccu,FP=nn,LP=mim,CYL=ppp,DISK=tttt 
where 


cccccc is the volume label of the receiving DASD 
volume; 

ecu is the channel, control unit, and device address of 
the receiving volume; 

nn is the page number of the first page to be written 
(in hexadecimal); 

mm is the page number of the last page to be written 
(in hexadecimal). 

ppp is the starting cylinder of the image; 
tttt is the device type (either 2311 or 2314). 


The space indicated on the card m.ust have been previously 
allocated as permanent space on the volume (see "SAVESYS" 
under "Utility Operation" in the CP-67 Operator's Guide , for 
format conventions). The information on the control card 
must match that information provided in the SYSTEM module 
assembled and loaded with the system. In that module the 
systemi name, location, shared pages, if any, and operating 
conventions are established. In the distributed SYSTEM 
module, the system name is CMS, and eighteen pages are 
saved, beginning at page 0, up to and including page X’ll*. 
The saved copy of CMS is written on the 2314 volxime labeled 
CPDSKl at cylinder 200. 


The SYSTEM SYSIN file is constructed using a SYSTEZ-! 
macro, which has the format 

SYSTEM NAME=nnn,FIRSTP=aa,LASTP=bb,TABLE=ttt, 

VOLID=xxx,EXADD=ccc,SYSMASK=sss,RUNKEY=kkk, 
SYSTAB=yyy 

where 

nnn is the name for the system; 
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aa is the first page saved? 
bb is the last page saved? 
ttt is the label of the S^'TPTABLE macro 
associated with this system; 

XXX .is the label of the volume on which the 
system is saved? 

ccc is the virtual machine execution address; 
sss is the virtual machine system mask; 
kkk is the virtual machine protection key; 
yyy ^is the label of the shared page table 
in PAGTRANS if this system has shared 
pages; otherwise it is zero. 

The SWPTABLE macro used with the SYSTEM macro has the 
following format; 

ttt SWPTABLE DASDORG=ccc,FIRSTP=aa,LASTP=bb, 

FIRSTSP=xx,LASTSP=Yy,DISK=ddd 

where 

ttt is a label (same as ttt in SYSTEM macro); 

ccc is the cylinder address where the system is saved; 

aa is the first page saved; 

bb is the last page saved; 

XX is the first shared page, if any; 

yy is the last shared page, if any; 

ddd is the disk type where saved, 2311 or 2314, 

The SYSTEM macro builds a table to define the name and 
running attributes of the saved system. The SWPTABLE macro 
builds a model SWPTABLE that is mapped to the virtual 
machine SWPTABLE in core to give that machine access 
(through paging) to the saved system. 


The number of cylinders required to hold a named system 
depends upon the number of pages saved and the device type. 
For a 2314, one cylinder holds 30 pages; a 2311 cylinder 
holds 8 pages. Thus, CMS with 17 pages requires one 2314 
cylinder or three 2311 cylinders. 


When SAVESYS saves a copy of the system, it saves from 
FP to LP- If LP is greater than X'20', the SAVESYS module 
must be loaded into higher core, as it normally loads into 
X*20000*. To load SAVESYS into higher core, change the 

address in the SLC 20000 card et the front of the SAVESYS 

text deck. 

The procedure for creating the page-form copy is as 
follows: 

1. Load the required system into memory, with the address 
stop switches set to a location within that system 

where execution may be resumed witiiout ehe system 
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assuming any previous state in the machine (that is^ 
registers, lower core locations, etc.). For CMS the 
address stop location is X*F0*. 

2. When the system has entered manual state (that is, the 

address has been reached), load the SAVESYS deck into 
the system card reader and load from the reader. 

3. If the save was successful, a message appears on the 
operator's terminal to that effect. 

Note . The following procedure must be used to run 
Version 2 of CMS under Version 3 of CP as the named 
system CMS: either the SYSTEM module must be changed 
in CP, as Version 2 of CMS has only 3 shared pages, or 
the saved copy of Version 2 of CMS must be given a name 
other than CMS. 


See "Saving CMS under CP-67" in this manual for 
details of preparing CMS for the CP-67 SAVESYS 
function. 


CP-67 MAINTENANCE PROCEDURE 


When corrections have to be made to a CP-67 module, a 
PTF is made available to the installation through the normal 
channels. The PTF is in a form suitable for a CMS OFFLINE 
READ or TAPE LOAD function depending upon the distribution 
medium. A special EXEC procedure is distributed to be used 
when applying PTF's. A description of the use and function 
of this procedure is given below. 


C PPTF EXEC 

CPPTF 61 62 

where 61 is the name of the CP-67 module to receiv-’ 
the PTF and 62 is the PTF number (for example, CPPiF 
DISPATCH A32486CA). Having first loaded the PTF on 
to the maintenance P-disk (using OFFLINE READ or TAiE 
LOAD) the user then issues all necessary CPPTF EXFC 
procedures to effect the change. One PTF may Involve 
changes to several modules. For instance, PTF ni ; . . : 
A32486CA may create (through loading on to the 
P-disk) the following files: 

DISPATCH A32486CA 

PAGTRANS A32486CA 

UNSTIO A32486CA 

The user must then-issue the following CMS coimmanGSt 



CPPTF DISPATCH A32486CA 
CPPTF PAGTRANS A32486CA 
CPPTF UNSTIO A32486CA 

The function of the CPPTF is as follows; 

The PTF file (for example, DISPATCH A32486CA) is 
applied to the corresponding SYSIN file (that 
is, DISPATCH SYSIN), using the CMS UPDATE 

, program- The PTF creates a new SYSIN file 

replacing the original . If the installation 
wishes to preserve the original SYSIN file, it 
should be saved beforehand or copied and given a 
new name. Once the new SYSIN has been created, 
it should remain on the disk (or be available) 
since further PTF*s that may be applied to the 
module may require that a previous PTF be 
applied first. The CPUPASM EXEC procedure is 
then ihvoked to assemble the new SYSIN file. If 
the installation has its own UPDATE file, 
CPUPASM applies it to the now modified SYSIN. 
The installation should check that any UPDATE 
file interfaces correctly to the SYSIN file once 
PTF*s have been .applied. The CPPTF EXEC 
procedure finally punches the 61 TEXT file, 
prints a completion message, and exits. 




TUNING OF CP-67 


To prevent paging overload, CP-67 allows only a subset 
of the users to be dispatched at one time. There are two 
queues for such users; both queues are served round-robin, 
and the queued user remains in the queue until he has used 
an allotted amouftt of computer time. A user enters QUEUEl 
whenever he issues a carriage return from his terminal. He 
stays in QUEUEl until the time quantum (400 milliseconds) is 
used or his virtual machine requires more console activity. 
If a user exceeds the QUEUEl time quantum, he is placed in 
QUEUE2 or queued to be placed in QUEUE2, which has a time 
quantum of five seconds- The QUEUEl time quantum is set to 
allow an average edit request to be serviced. 


The paging algorithm is tied to this dispatching 
system.. Whenever a page of memory is required, PAGTRANS 
uses a page assigned to a user who is not in QUEUEl or 
QUEUE2 (and thereby paging runnable against unrunnable 
users). The intent of this queue structure is to set a limit 
on th€' number of tasks that can compete for computer 
resources (memory and cpu), and to segregate short execution 
tasks (for example, edit requests) from long execution tasks 
(for e>:ample, FORTRAN compilation). By so segregating the 
tasks, limiting the number of long execution tasks, and 
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can be avoided. 


The queue sizes are autoinatically adjusted at system 
IPL time based upon real core size. The queue sizes for 
various core capacities are 

256K 512K 768K IM 
Q1 3 6 9 12 
Q2 1 3 6 9 

The operator has a console function to change the size of 

Q2. 







INSTALLING CMS 


DUMP/RESTORE UTILITY 


To create a CMS System disk, place the distribution 
tape on a tape drive, address OCUU. Clear core and IPL the 
tape by pressing the LOAD button. When the wait light 
remains on, and the system and load lights go off, hit 
REQUEST ** on the online console. DUf'P/RESTORE is given 
control. 


CMS may be restored under CP-67, if CP already exists. 
Merely, attach the tape to a virtual machine and issue IPL 
ecu. Produce an ATTENTION interrupt. 


The console address is dynamically set. If replies are 
' incorrect while the DUMP/RESTORE is executing, DMPRST 
reinitializes itself and repeats Question 1. If an I/O 
error is sensed on the disk or tape, it tries to rectify the 
error- condition. If successful, it continues. If not, it 
prints out a message and terminates. 


Termination, either after a successful operation or 
because of an error, places the CPU in the wait state. 


Ql; TASK? ("DUMP" , "REST"); 
DUMP—disk to tape 
RESTORE—tape to disk 


Q2; DEVICE TYPE? ("2311" , "2314"); 
specify the disk device type 


Q3; TAPE ADDRESS? ("OCUU"); 

self-explanatory. Must enter a four hexadecimal 
reply (for example, 0181, 0275) 


Q4; DISK ADDRESS? ("OCUU"); 

self-explanatory. The reply must be four 
hexadecimal digits (for exam.ple, 0191,0290). 


REWIND TAPE? ("YES" , "NO"); 
ibis applies r.o before and after the operation. 
Obviously, since the tape after IPL is positioned at 
its second file, the answer must be NO. 


Q5: 





Q6: OTKBER OF CYLINDERS? C”0NNN”):, 

self-explanatory. The reply irast be four decirr.al 
digits (for example, 0203, 0100). For restoring the 
distribution tape, specify 203 cylinders for a 2311 
or 54 cylinders on a 2314. 


Q7: STARTING CYLINDER? ("ONNN"): 

» self-explanatory. (For the system disk, reply; 

" 0000 ".) 


Q8; BEGINNING OF TAPE? ("YES" , "NO"); 

The answer determines if a tape mark is to be written 
ahead of the file. If YES, a tape mark is written; if 
NO, the EOF at the end of the previous file serves as 
the tape mark for the beginning of this file. (When 
restoring the distribution tape, 08 is not asked.) 


The DUMP/RESTORE operation begins after the last 
question is answered. If either device is not ready, the 
program waits for its ready state. When restoring, the disk 
need not be formatted or DASDI’ed. D^'!PRST formats the disk 
as it is being restored. 


Upon encountering an EOF, satisfying the amount of 
cylinders specified in Q6, or executing a SEEK beyond the 
disk limits, the operation terminates with the message 


•DUMP/RESTORE EOVED nnn CYLINDERS 
THERE WERE nnn RECOVERABLE TAPE ERRORS.' 


TASK? ("DUNP","REST"); restore 
DEVICE TYPE? ("2311","2314"); 2314 
TAPE ADDRESS? ("OCUU"); 0181 
DISK ADDRESS? ("OCUU"): 0190 
REWIND TAPE? ("YES","NO"): no 
NUMBER OF CYLINDERS? ("ONNN"); 0054 
STARTING CYLINDER? ("ONNN"); 0000 
BEGINNING OF TAPE? ("YES","NO"); no 
DUMP/RESTORE MOVED 054 CYLINDERS. 

THERE WERE 001 RECOVERABLE TAPE ERRORS. 


Figure 1. Restore procedure for CHS distribution tape 







CMS SYSTEM 


Tn*'rr«v 


Once restored, the CMS Systein disk assumes the 
following appearance: 

\ 

rlock Information 

0-2 *' IPL pointers, CCW*s, etc. 


3 label = CMS190 


4 Master File Directory 


5-7979 


1. Nucleus Text decks in one file called NUCLEUS 3.0, in 
which each individual text deck is preceded by an 
OFFLINE READ filename TEXT card. The nucleus text decks 
are also present individually. 

2. Disk Command Modules. 

3. Disk Command Texts. 

4. EXEC Procedures 


7980-8100 

IPL’able Nucleus (0-12000x and loader tables). 


The nucleus routine, NUCON, contains a device table. It 
has been initialized as follows: 


S-Disk 

= 

0190 

P-Disk 

= 

0191 

T-Disk 

= 

0192 

CONSOLE 


0009 

CPEADR 

= 

OOOC 

PRINTER 


OOOE 

CPUNCH 


OOOD 

TAPI 

= 

0180 

TAP2 


0181 

DSK4 


0000 

DSK5 

= 

0000 

DSK6 


019C 

CRTl 

= 

0106 


These 
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are the standard 


CMS machine device addresses. 




= SYSI^) of every CMS routine. 


j^LTERING THE CMS SYSTEM DISK 

NUCLEUS 


After restoring the CMS Source Disk, IPL CMS. Use the 
CMS Source Disk as a P-disk, 191. Log in and issue the 
comniand 


OFFLINE PUNCH NUCLEUS 3.0. 

The file punched, about 1800 cards, contains all the text 
decks that constitute the CMS nucleus. The cards should now 
be interpreted. Separating the individual text decks is an 
"OFFLINE READ name TEXT" card. Keep this nucleus deck. It 
is needed whenever changes are to be made to the contents of 
the System disk. (NUCLEUS 3.0 is also on the CMS System 
disk.) 


The LOADER deck supplied is used to IPL the nucleus 
under CP (that is, it recognizes the standard CMS virtual 
device addresses). If the nucleus is to be IPL'ed on 
incompatible device addresses, the loader deck (first deck) 
must be replaced with the appropriately addressed loader. 


The CMS nucleus may also be created by using the two 
EXEC procedures on the system disk—JPUNNUC and NUCLEUS!. 
Issue the command NUCLEUS! EXEC JPUNNUC userid/OFF. Each 
component text deck of the nucleus is punched. If a userid 
was specified, the deck is XFER'ed to that userid. If OFF 
was specified, the physical card deck is punched. 


IPL'ABLE SYSTEM DISK 


Tc rewrite the IPL*able nucleus onto the CMS System 
disk, place the nucleus in the card reader and press the 


button. 


Under CP, 


the.nucleus deck into the CP 


card reader with the appropriate ID card, or use the EXEC 
procedure NUCLEUS! and XFER the deck into the card reader, 
then type the CP command IPL C. The nucleus is loaded into 


CO" 


’kace; 


ved. 


^ "n a 


pi\; Ail iir^u'-'auxe ccre-irnage copy of uhe nucleus 

(lcc3.tjoas 0-12000) irav row he written onto disk. 





After the IPL sequence has coirpleted, the IPLDISK 
routine is given control. It expects the standard console 
(terininal) address (009). If it is other than 009, the wait 
state is entered, and IPLDISK accepts an ATTENTION interrupt 
in order to define the console address. The following 
information is then sought: 


"REWRITE NUCLEUS? (YFS,NO)": 

YES—a new IPL*able copy of the CMS nucleus is to be 
written onto disk 

NO —no writing takes place, control returns to INIT 
(CMS initialization routine) 


"DEVICE ADDftESS? (0CUU,SYS)": 

A core-image copy is written onto device OCUU (if 
specified) or onto SYS, which is the System disk 
address specified in the nucleus device table. 

"STARTING CYLINDER? (0XXX,SYS)": 

The core-image copy is placed at cylinder 
OXXX—hexadecimal representation—or on the SYS 
cylinder. The SYS cylinder is 



cc 

hh 

rr 

block 

2314: 

53 

04 

00 

7980 

2311: 

199 

05 

00 

7980 


"VERSION IDENTIFICATION (15 bytes)": 

Fifteen bytes of information, including blanks, are 
used as the version title and are printed out when 
IPL'ing the CMS nucleus. 


An IPL'able copy of the CMS nucleus (locations 0-12000) xs 
written onto the specified disk. A load map showing all deck 
names and reference points for the nucleus is written to 
system printer device. There are four unresolved symbols a‘: 
the end of the load map, as follows: 

LOGIN, OFFLINE—may be either nucleus or 

disk-resident commands. 

BATCH, SYSCTL—external references for the Ear.c.i 
Nucleus. 


SAVING CMS UNDER CP 


invoked, CP allows 


r-'O T* 


>A vT 


CC“ 




the CI]'s nucleus, so that a user may invoke CMS by issuing 
the CP comniand TPL CMS. 

To save CMS, IPL the CMS Systeii' disk on the bare 
machine (that is, not under CP). Cause an ATTENTION 
interrupt on the console. 


The following is typed: 


Ql: REDEFINE DEVICE ADDRESSES? ("YES","MO")_ (reply MO). 

This question is asked when running CMS on the bare 
machine to allow the user to dynamically change the 
standard device addresses. 


Q2: WILL THE CP-SAVE FUNCTION FOR CMS BE EXECUTED? 

("YES","NO")_ (reply YES). 


Cl: ALL DEVICE ADDRESSES MUST BE ENTERED AS 4 HEXADECIMAL 

DIGITS: "OCUU". 


Q3: ENTER THE "REAL" address of the CMS SYSTEM DISK... 

reply "OCUU", where CUU is the real online address of 
the CMS system disk—as opposed to virtual address 
190. 


Q4; SET THE "ADDRESS COMPARE" SWITCH FOR LOC X’FO*; REPLY 
"•GO" After setting the instruction counter switches to 
reflect hexadecimal location *FO', and setting the 
"address compare" key "on", reply "GO". 


C2: WHEN "M^ANUAL" STATE IS ENTERED, IPL THE CP "SAVESYS" 

UTILITY DECK FROM THE CARD READER 


When the CPU stops at location X*F0', place the CP SAVESYS 
utility deck with loader and control card into the real card 
reader, reset the load address on the CPU console, and IPL 
the card reader. The message NORM-AL TERMINATION OF SAVE 
FUNCTION is typed. 


EXEC PROCEDURES 


-GEND is used to create overlay structures for the OS 

T r?1 r .c:. ’"a rr ^ V-^ i* ;r* 

pro^uciiig ruoaaies. These -GEND EXEC procedures 
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are used only when creating the overlay irodule 
structure. Do not tiry to use them when the text 
decks of the processor components are not 
present. For re-genirtoding the interface 
modules, use the respective GENDALL EXEC 
segment. No arguments need be passed to -GEND 
procedures. 

GENDALL indicates which modules contain auxiliary 

^ directories. When changing the base command 

module, or moving the secondary processor 
modules, the GENDIRT command must be used. 
GENDIRT is used to complete auxiliary file 
directories. It is to be used by the system 
programmer when creating modules containing 
auxiliary directories. GENDALL requires the code 
name of the specific language processor to be 
passed as the only parameter (for example, 
ASSEM, FORT, PLI). 

CMSGEND shows the method of creating all CMS 

disk-resident modules. The name of the disk 
module to be created must be passed to CMSGEND 
(for example, to create the TAPE module, issue 
the command CMSGEND TAPE). 

NUCLEUS3/JPUNNUC is used to create a physical CMS nucleus 

deck by punching each individual TEXT deck. 
Issue the command: NUCLEUS3 EXEC JPUNNUC userid, 
where userid is the identity of the virtual 
machine to which CMS nucleus deck is XFER'ed. 



MAINTAINING THE CMS SYSTEM DISK 


To add or change coimnands in the nucleus or on the 
system disk, proceed as described below. 

CMS MAINTENANCE PROCEDURES 


To update the Version 3 CMS ’ system the procedure 
described below must be applied. 

When a PTF is received, the user should apply it to his 
Version 3 SYSIN deck. The PTF is an update deck identified 
as "filename AxxxxyCA", where filename is the name of the 
routine to which the update is to be applied and AxxxxyCA is 
the filetype. xxxx is the APAR number, and y is the APAR 
code that the PTF corrects. 

Example: 

V3 deck ’edit sysin* 

Update * edit AxxxxyCA' 

The command to issue is UPDATE EDIT SYSIN EDIT 
AxxxxyCA (seq8 inc P) 

The "seqS" allows sequencing of up to eight digits. 
The "i.nc" includes the sequence number of the update card 
into the new updated sysin file. The^ P causes a newly 
updated SYSIN file to be created. 

The updated file created is "edit sysin". 

Note . The original "edit sysin" is replaced with the 
updated copy. 

CMSPTF EXEC : 

The updating process described previously can be 
executed with the aid of a CMS EXEC file called CMSPTF EXEC. 

This EXEC procedure takes the original SOURCE deck and 
the P^F deck and creates the new SOURCE deck, assembles it 
producing a TEXT deck, prints an UPDATE LOG of the update 
changes, and an assenbly LISTING onto the offline printer, 
and offline punches the TEXT deck. 

Ihis enables the user to update and get a copy of the 
new object deck in a one-step procedure. 
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CHANGING DISK-RESIDENT COMMANDS 


As above, obtain the object deck of the new coininand. 

Using the systeiri disk as a P-disk, offline read the 
text deck of the new coiritiand. Then create a workable module 
by issuing 

LOAD name (TYPE CLEAR) 

GENMOD name {P2) 


All system modules must have a filemode of P2. 


If the new command is a transient routine, issue the 
following: 


ERASE name MODULE 

LOAD name (TYPE TRANS) 

GENMOD name {P2) 

All system modules must have a filemode of P2. 

The CMSGEND EXEC procedure may be used to generate any CMS 
disk-resident command. Merely issue the command "CMSGEND 
name", where "name" is the title of the TEXT and MODULE of 
the desired routine. 


C-DISK AS A READ-ONLY EXTENSION OF S-DISK 


In some installations, it may be desirable to have an extra 
disk as a read-only extension of the standard S-Disk. This 
may prove useful for one of several reasons: 

1. If the system customarily has a large number of users, 
it can provide a more efficient utilization of system 
resources to place some of the system disk programs and 
libraries on one disk pack, and others on another pack. 
If somie of the programs and/or libraries currently on 
the S-Disk are placed on another disk instead, this can 
be accomplished. 

2. If a system disk gets very full from addition of new 
programs, it may be advisable to put new added prograrrs 
on an extra disk instead of adding more cylinders to 
the S-Disk. 

3. It may be that certain new or restricted programs are 
to be made available to a limited number of users. In 
this case, such oroarams could be out on- the 



nermitted to use s'ach -Droq-rams. 




CMS now has the capability to provide such an ^xtra disk as 
a read-only extension of the S-Disk. This extra disk is the 
C-Disk, and has a default disk-address (in the NUCON table) 
of 019C. If it is desired to use the C-Disk as a read-only 
extension of the S-Disk, the following steps must be taken, 
and the CMS initialization procedure does the rest: 

» 

1. Compilers and any other programs which require the 
GENDIRT procedure must be on the S-Disk. lEM-supolied 
programs in CMS requiring GENDIRT currently are the 
Assembler, FORTRAN, and PL/I. 

2. Create the desired modules on the extra disk using the 
same procedures you would for any read-write disk (for 
example, by OFFLINE READ of text decks, COMBINE, TAPE 
LOAD, DISK LOAD) but taking care to ensure that the 
modules or libraries which are to be user-accessible 
have a P2 mode (as on the S-Disk). (See also “Altering 
the CMS System Disk"—CMS EXEC Procedures.) 

3. Run an update deck called CDISK UPDATE against the lADT 
SYSIN deck in the CMS nucleus. That is, with lADT 
SYSIN and CDISK UPDATE available, execute "UPDATE lADT 
SYSIN CDISK UPDATE (SEQ8)", assemble the resulting 
.lADT SYSIN, and then place the .lADT TEXT in the CMS 
nucleus using the procedures described above under 
"Changing Nucleus Resident Commands". 


The aforementioned CDISK UPDATE deck changes the 
description of the C-Disk at ADTC in the lAOT Initial 
Active Disk table to flag the C-Disk as a read-only 
extension of the S-disk, and should be as follovjs: 

s 

// R 20000 

C-DISK (READ-ONLY EXTENSION OF S-DISK) 

// R 239000 240000 

DC 1C*S* C-DISK = READ-ONLY EXTENSION OF 

DC ALKADTFRO) FIRST FLAG-BYTE (READ-ONLY BIT 

4. Place the C-Disk as a read-only disk in the virtual 
machine descriptor in the CP directory, with virtual 
address 19C, for all users who are to have the C-Disk 
available to them. 

If these steps are followed, and the C-Disk is attached and 
ready at CMS Initialization time, while the version 
identification message is being typed, CMS automatically 
logs in the P2 files from the C-Disk, as a read-only 
extension of the S-Disk, in a manner similar to the SYSGEN 
function for obtaining the SSTAT table from the S-Disk. 

The C-Disk is then a read-only extension of the S-Disk, 
transparent to miost CMS commands. STAT C gives the 
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disk-sbatistics•on the C-Disk (as STAT S does the standard 
S-Disk>, and LISTF filename filetype C lists the C-Disk 
files just as LISTF filename filetype S does the standard 
S-Disk files. (LISTF and STAT purposely do not attempt to 
handle read-only extensions of disks, to avoid ambiguity.) 


CMS CONSIDERATIONS 


FORMATTING THE P-DISK 


Once the CMS System disk is restored and all device 
addresses are assured correct in matching either the bare 
machine configuration or the CP allocation directory, issue 
an IPL to the System disk. 


Initially, each user must issue as his first command 
FORMAT P ALL. This command formats his P-Disk for CMS usage. 
If the disk is not formatted, I/O errors occur when 
accessing the P-disk. 


Note . All disks that are to be accessed by users must 
be formatted in the same manner as above. 


Version 3—Version 2 Compatibility 


The disk formats for Version 2 and Version 3 are 
compatible; however, the internal core tables are 
incompatible between these two versions of CMS. 

Do not use old commands such as V2L0 or V2L1 which 
manipulate files with Version 3 (such as LOGIN, LISTF, 
OFFLINE, ERASE, TAPE, DISK, FORMAT, and START) as they do 
not work. 

If a previous version of CMS is to be examined, log it 
in as a C-disk so that it will be searched last ' and its 
routines will not be used in place of the system routines. 


OBTAINING A NUCLEUS tCLD NAP 


A load map of the nucleus, giving the name and cere 

location of each nucleus routine, may be obtained by 




TPL IQO 




login on any foririatted F-disk 


MAPPRT B OFF (see oldier options for this 

command in CP-67/CMS User's Guide) 


^he file CMS-NUC ALPHANUM PI is created on the P-disk and is 
also printed offline. 


P-DISK CONSIDERATIONS FOR THE BARE MACHINE 


When operating on the bare machine, the P-disk is used 
from real cylinder 0. Therefore, if a user wishes to use 
his own files on the bare machine, his files must be 
physically located on real cylinder 0. 


The user must also be aware of his P-disk size when he 
is operating on the bare machine. If more files are created 
than he has disk space, CMS is not aware that the user has 
less than 203 cylinders and allows the user to create the 
files over the entire disk pack if the space is needed. 


COMMAND ABBREVIATIONS 


When a CMS command is issued from the terminal or from 
a routine, several tables are searched for the comm,and name. 
If no command is defined for the name, CMS assumes that a 
command abbreviation was used. The nucleus-resident routine 
ABBREV is then searched to verify and find the full-name 
equivalent of the command. Command abbreviation is defined 
as the minimum number of characters necessary to recognize 
the full command nam.e. 


If standard system abbreviations are not to be allo'-.-ed 
in CMS, the ABBREV TEXT deck should be remove^ from the 
nucleus deck. 


To change, add, or delete an abbreviation, the ABBREV 
routine must be reassembled, altering the abbreviaticr. t,.. . 

as desired. The table is constructed using the macro AERV 
as follows: 

ABRV name, number 

where name is the full name of the command, and number is 

the - 1 '"’"'her of characters which ':rs acce'-'t’'.'’ 
abbreviation. 



> 

The iracro must be used for each desired coiranand 
abbreviation. For example: 

ABRV OFFLINE, 1 

signifies that the acceptable abbreviation for the command 
OFFLINE is O (also, OF, OFF, OFFL, ...). 

«> 

ABRV ALTER, 2 

states that the abbreviation for ALTER is AL (also, ALT, 
ALTE, ALTER). 


INSTALLATION OF THE CFiS BATCH MONITOR 


From the CMS System disk obtain a copy of the Batch 
Monitor Nucleus, BATNUC 3.0, by issuing the command OFFLINE 
PUNCH BATNUC 3.0. 


Set up a disk area that is used only by the virtual 
batch machine. This disk area, address ecu, contains the 
IPL'able copy of Batch nucleus and need be only tv/o-2314 
cylinders, or four-2311 cylinders. Also, set up a P-disk, 
191, for the Batch machine. 


Write an IPL'able copy of the Batch nucleus, BATNUC, 
onto disk ecu in the same manner as the CMS nucleus is 
reloaded onto the System disk. Two comments: 1) in 
refer€>nce to Q2 about device address, reply Ocuu, where cuu 
is the disk address specifically defined for the Batch 
machine; 2) for Q3, answer ONNN, where NNN is an integer 
whose absolute value is greater than zero but less than the 
integer value of the number of cylinders allotted to the 
disk area. 

After writing the Batch nucleus onto cuu, the message 
READY is typed. The Batch Nucleus disk, cuu, must be IPL'ed 
before executing any Batch Job Streams. 


I’o run a CMS Batch job stream,, first it is necessary to 

IPL CUU. The Batch nucleus may also be SAVE'd by CP, using 

the r.ame BATCH. If the name BATCH is undesirable, a 

different name may be used by changing the CP routine 
SYSTEM, which contains the names and descriptions of all 
IPL'able named systems. Batch nucleus has set a time limit 
per job (five minutes) and an output limit per job (5000 
pointex lines). These limits may be modified by 

reassemblinc the routine BATJCB and placing the new copy 

i ■ , ■■■ t- i ; J. w ,1 11 r* “w X. , - i -,1? . 
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SAMPLE PROBLEM 


A sample problem is distributed as File 5 on the tape 
containing the basic program material. It exists in TAPE 
gUMP form. • 


To load the sample problem onto the P-disk, position 
the tape after the fifth tape mark and load it from tape. 
This is done by issuing 
TAPE REWIND 
TAPE SKIP 4 
TAPE LOAD 

Then the pro'gram is ready to be compiled and executed. 


The complete procedure for logging in, IPL'ing 190 for 
CMS, FORMAT*ing the P—disk, loading the FORTRAN source deck 
on the P-disk, and then compiling and executing the sample 
problem is shown in Figure 2. System responses are printed 
in uppercase; user-entered information is typed in 
lowercase. Figure 3 contains a listing of the file SAMPLE 
FORTRAN. 



C SAMPLE PROBLEM FOR TESTING CP-67/CMS TYPE III DISTRIBUTION 

C 

1 PRINT 100 

100 FORMAT (• PLEASE TYPE IN THE NUMBER OF VALUES TO AVERAGE*) 
READ 101, N 
1»1 FORMAT (12) 

IN (N) 2,99,2 

2 PRINT 105 

105 FORMAT (’ FIRST NUMBER? (FORMAT IS F10,4)') 

READ 103, SUM 

M=N-1 

DO 3 1=1,M 
PRINT 102 

102 FORMAT (' NEXT NUMBER?*) 

READ 103, X 

103 FORMAT (FlO.4) 

SUM = SUM + X 

3 CONTINUE 
Y = N 

AVG = SUM/Y 
PRINT 104, AVG 

104 FORMAT (15X, 'AVERAGE = *,F10.4) 

GO TO 1 

99 PRINT 106 

106 FORMAT (* ♦** TEST COMPLETE WELCOME TO CP-67/CMS! *) 

STOP 

END 


Figure 3. Listing of SAMPLE FORTRAN 
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